[レポート] AMT305 – AWS で BMW グループのカスタマーエンゲージメントプラットフォームを構築する #reinvent

こんにちは。池田です。本記事は現地時間2018/11/26-30で行われたre:Invent 2018のセッション AMT305 - Building BMW Group's Customer Engagement Platform on AWS（AWS で BMW グループのカスタマーエンゲージメントプラットフォームを構築する）のセッションレポートです。

概要

In today's "always connected" world, brands must find unique ways to engage customers anywhere, anytime and across an ever-changing variety of formats. Large enterprises are often challenged by aging, monolithic applications that limit their ability to adapt quickly to changes. In this session, the BMW Group discusses how it is using microservices on the AWS Cloud to transform its customer engagement platform. Learn how the company built its Unified Configurator Platform (UCP) to serve 30+ branded customer-facing applications with over 300 RESTful API endpoints using services such as Amazon API Gateway, AWS Lambda, Amazon Elastic Beanstalk, and AWS Elastic Container Service. Additionally, the BMW Group discusses how Game Days and Chaos Monkey methodologies led to the success of the overall program.

動画・資料

セッション資料は以下に公開されています。
Youtube動画

登壇者

Constantin Gonzalez - Principal Solutions Architect, AWS
Patrick Lanners - Solution Architect, BMW Group
Julian Roedig - Principal Solution Architect, BMW Group

セッションレポート

まず最初の5分ほどで Constantin Gonzalez によってモノリシックシステムとマイクロサービスそれぞれの特徴、そしてマイクロサービスの利点についての解説がありました。

モノリシックシステムの特徴

• Rigid
  • 巨大な一つの厳格（窮屈？）なアプリケーション
• Hard to scale
  • スケール（拡張）が難しい
• Hard to deploy
  • 拡張が困難になる傾向に加えてデプロイも困難
• Locked-in
  • 変更が困難であることなどからロックインされていると感じられる傾向がある
• Hard to reuse
  • 巨大なシステムが故に再利用が難しい
• Easy to break
  • 小さな変更による不具合が生じた場合でもシステム全体が停止するケースが多い

また、開発においても巨大化、複雑化しやすく構築、テスト、リリースのサイクルが過酷な労働となりがち...

マイクロサービスの特徴

• Autonomous
  • それぞれが自立している
• Specialized
  • 一つの目的に特化されている
• Agile
  • 結果としてアジャイル（機敏）になりがちである
• Flexible to scale
  • 非常に柔軟に拡張が行える
• Easy to deploy
  • 非常にコンパクトなのでデプロイも容易である
• Freedom
  • （これまでに挙げた理由から）開発者は従来よりも自由な時間を得て新たなシステムや技術習得をすることができる
• Easy to reuse
  • コピー&ペーストで簡単に複製したり、新たなマイクロサービステンプレートとして利用できる
• Resilient
  • 万が一サービスに不具合があっても影響は特定のサービスのみで、システム全体へは影響が出にくい

モノリシックシステムからマイクロサービスへ

ここからは Patrick Lanners による事例紹介となります。
まずユースケースの紹介として、BMW グループのウェブサイトに設置されている CONFIGURATOR PLATFORM のお話。これはコンフィギュレーターという WEB サイト上にあり、車両に適用できる全てのオプションを自由に選択し、それらが適用された状態の写真や価格を表示させる仕組みでした。実際にアクセスしてみたのが以下です。

車やバイクの色、オプション装備を選んだ際の内装の変化などをスムーズに確かめることが出来ました。

このコンフィギュレーターで利用している API は月間約1億の呼び出しを受けており、BMW グループ全てのブランドと市場に対応しているそうです。これは現在、AWS 上でマイクロサービスを利用しているのですが、以前はモノリシックシステムであったとのことです。

MONOLITHIC SYSTEM ISN’T BYDEFINITION A BAD THING

モノリシックシステムも悪いものではない。として以下が挙げられています。

• 利点
  • 量産対応が可能となる迅速な開発
  • 分散システムの課題に対処する必要がない
• 次のステップに進むための課題とシステム移行を推進する要因はある
  • 要件数の増加により、全体的な複雑さが増したために新たなシステムへ移行することを検討し始めた

AWS への移行を進める際に用いた “LIFT-THINK-SHIFT” というアプローチ

• API仕様と認証情報
  • Amazon API Gateway を利用
• Glassfish アプリケーションサーバー
  • AWS Elastic Beanstalk による Docker + Glassfish アプリケーションサーバーを実現
• DB Import Job
  • JAVA のコードへ書き換えることにより Amazon ECS + AWS Batch で実現
• ORACLE DB
  • Amazon RDS PostgreSQL へ移行することでライセンス費用の削減も実現

single entry point to oure services

• 顧客がシステムへアクセスする入口はひとつとした
  • Route53 に登録されたパブリックドメインへアクセスさせる
• cloudfront を経由してAPI Gatewayへ
  • API Gateway からLambdaを経由してDynamoDBにAPI KEYを格納
• リクエストが認証され次第、 VPC LINK を使って VPC へのエントリポイントを取得
  • ELB、EC2、DB はそれぞれ異なるサブネットに配置
• VPC LINK は現在のところネットワークロードバランサーとのみ連携しているため、異なるマイクロサービスに対処する方法についての解決策が必要だった
  • Elastic Beanstalk と nginx を利用した
  • nginx から他のマイクロサービスへリクエストを転送することにした

Architecture deep dives

ここから Julian Roedig のターンです。Deep Dive と題するだけあって、一つひとつを大変詳細に解説されています。ここではそれぞれのテーマで記事になりそうなボリュームだったので概要のみにとどめますが、興味のある方はぜひ動画（15分23秒から）をご覧ください。

service discovery

• VPC 内でRoute53による内部ドメイン名を解決、各マイクロサービスへのアクセスを可能にしている
  • たとえば、ヒープサイズ設定やプールサイズ設定を別の EC2 タイプと組み合わせて変更する場合や、新サービスをリリースする場合のリスク対策として Route 53 の加重レコード（ Weighted Records ）を利用しいる
• DNS ベースのサービス検出によって柔軟性の向上を図った

AWS Lambda CI/DI

• 自動化された CI / CD パイプラインにより、Lambda Function の新規呼び出しを安全にすることができた
• コードは S3 と CloudFormation Sftack に配置され、S3 から CodeDeploy によって実行される
• Amazon CloudWatch がエラーを検出すれば CodeDeploy によって処理は停止しロールバックされる

Offline data processing

• ECSを介してオンプレミスデータソースからのデータをマイクロサービスに転送する必要がある
  • また、世界各国の市場に向けたバッチジョブをそれぞれ適切なタイミングで実行する必要もある
• 適切なタイミングで適切なジョブを実行するために、Amazon CloudWatch Events と AWS Lambda をスケジューラとして使用

  Advanced Lambda use case

• BMW の CONFIGURATOR PLATFORM 上では数千もの constructability rutes （その組み合わせは実現可能か、利用可能なオプションとして提供されているかなど） をチェックする必要があり Lambda Functions を活用している
  • 車両をカスタマイズする際に行われるが、数百の構成に対するチェックは1-2秒で完了する
• しかし、1日に数回しか呼び出されないことから並列実行数を50に制限している

Environments on demand

• オンデマンドの開発環境は自動テストを行う上で重要である
• 開発チームは年間に何百ものリリースを行なっている
• Jenkins を用いて Git リポジトリに配置した CloudFormation テンプレートからマイクロサービスを起動させるので数分でテスト環境が構築できる
• インフラストラクチャの全体的な自動化によって開発チームに環境を提供できるようになった

Conclusion

• AWSへの移行から学んだこと
  • 分散モノリシックアプリケーションを構築しない
  • 完璧にしすぎない
  • 議論を続けるよりも、まず作ってみる
  • 継続的な学習と適応
  • AWSのソフトとハードの制限に注意し、それに応じてアーキテクチャを構築する
  • 考え方を根本から変えることは社内に大きな変革をもたらす（ Doing the transformation in-house was a game changer の日本語的言い回しが...）
  • 移行の開始時にAWSプロフェッショナルサービスをコーチとして検討する

Game Day を実施した話

Conclusion に進む前に、余談的に Game Day を実施したという話題がありました。Game Day とは模擬的にインシデント等を発生させ、トラブルシュートを行ない解決させるコンテストのようなものです。よく行われるのは、いくつかのチームに分かれて同じインシデントの対応を進め、より早く、より適切な対応を行ったチームにポイントが加算されていくやり方です。今回は以下のような内容で行なったと紹介されています。

• Solve real production scenarios
  • 実際のプロダクトにおけるシナリオを解決する
• Gamification is used through scoring and leaderboards
  • ゲーム的要素として得点をスコアボードに記録していく
• Chaos Monkey Team brings fun into the situation
  • 障害はChaos Monkeyを利用するチームによって、引き起こされる
• Each team gains points for
  • ポイントは以下の視点で配分される
• Availability of the system
  • システムの可用性
• Proposed improvements for DevOps-Cycle
  • DevOps サイクルの改善に関する提案

参加したメンバーの感想

楽しみながらインシデント対応におけるオペレーションを学べたとのことで、メンバーにも大変好評だったようです。インシデント対応を実際に行なったからこそ理解できることや、既存システムや手順の改善点が見つかったりするものですよね。やってみたいとは思いますが、実現するのもなかなかハードルが高いんだよなぁというのが筆者の感想です。

おわりに

普段は業務的にゴリゴリの開発をすることはないのですが、こういったセッションを聞くと、自分が利用したことのないサービスの仕組みや技術要素についての理解を深めることができ非常に楽しい気持ちになりました。特に英語によるセッションですので、何度も録画再生を一時停止しながら辞書を引き、メモをしながら整理して聞き進める。というプロセスが発生するので、もしかすると日本語で同じ話題を聞くよりも必死になっているからなのかもしれません。先日ご紹介した以下の記事を書いているときにも感じたのですが、オンプレミス環境で大きく育ったシステムをクラウドへ移行するのは一朝一夕で出来ることではないですし、また、一口にクラウドと言っても AWS だけで100を超えるサービスが提供されています。マッチするものを選定するだけでも大変な話かもしれませんが、こういった事例のようにクラウドならではの恩恵も計り知れないほどあるのではないでしょうか。

[レポート] DEM82 – 価値ある険しい道のり: AWSでJIRAをクラウドネイティブにする #reinvent